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ABSTRACT 



A conference enabled X windows networking system using 
a method for determining the best match available for a 
conference owner's visual type is disclosed. In the system, 
the enabler determines if the visual type detected in the X 
protocol stream is the conference owner's default visual 
type, in which case it is matched to the participant's default 
visual type. If mat is not the case, the system determines if 
a visual type is available on the participant which is com- 
patible to that being referred to in the X protocol. If so, the 
system determines which of the compatible visual types is 
the best match to that being used by the application. If there 
is an exact match of compatible visual type, the system 
matches the participant's visual type to that of the confer- 
ence owner. If there are no compatible matches, the system 
will determine if an incompatible match exists between the 
participant's available incompatible visual types and the 
visual type being used in the X protocol If there are no 
incompatible visual type available, the system signals an 
error condition and takes the appropriate action. When a 
match is made between a participant's visual type and that 
of the conference owner, the matched visual types are 
removed from the lists of available visual types. 

9 Claims, 3 Drawing Sheets 
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METHOD FOR MANAGING VISUAL TYPE describe the environment of that server. Many of these 

COMPATIBILITY IN A CONFERENCING resources are provided to the application when it imtuUy 

NETWORK SYSTEM HAVING connects to the X server. X server defined resources include 

HETEROGENEOUS HARDWARE « defined set of visual types that indicate the ways that the 

3 server may be used to display colors. Every application that 

CROSS-REFERENCE TO RELATED creates a window to display graphics on mat server must use 

APPLICATION one of these types. Every X server indicates which of these 

The present appHcatioo is related to U.S. patent applica- visual types is its default visuai 

tt» SenNo. 08/387,500, entitled Method and System For The X protocol defines a set of charac^sUcs of visual 

Zitching Between Users In A Conference Enabled Appli- » types used by vendors. Any vendor's LmplementaUon oftoe 

cation (Attorney Docket No. SA9-94-005) now U.S. Pat X server may chose to support ta subset of mese visual types 

No ^557,725, U.S. patent appUcation Ser. No. 0*387 ,502, and may chose to support ^rentsubsete of Oiese visuaj 

en^Me^ForMcmag^gTop^Level Endows Within A types based on the hardware (spedficaUy, the graphics 

cZZZing Network System (Attorney Docket No. SA9- adaptor) available to that X server. Therefore, a robust X 

2SS U S Sent appUcation Set. No. 08/387,501. 15 windows application should be able to determine the visual 

el^ilel Management And ^ of Events For An X types available to it and select the most appropriate visual 

Windows Conferencing Enabler (Attorney Docket No. SA9- type for that application. 

94-046). U.S. patent application Ser. No. 08/387,504, By way of definition, a visual type consists of three 

entitled Method To Support Applications That Allocate characteristics defined by the X protocol These cfaaracter- 

Shareable Or Non-Shareable ColorceUs In A Conferencing 20 istics are: 

Network System Having A Heterogeneous Hardware Envi- 1. Depth 

ronment (Attorney Docket No. SA9-94-122), U.S. patent Thflt . $ me DUmbcr of bit planes available for the display 

application Ser. No. 08/387*505, entitled Method For Man- of eac jj The X protocol, as well as current 

aging Pixel Selection In A Network Conferencing System graphics technology, defines a limit of 24 bits of depth. 

(Attorney Docket No. SA9-94-123), U.S. patent appUcation 25 By far ^ most common depths are 1, 8 and 24. 

Ser. No. 08/387,506, entitled Method And Apparatus For 2 Yisaa ^ dass 

Translating Key Codes Between Servers Over A Conference x wiudows defines six possible visual classes: 

Networking System (Attorney Docket No. SA9-94-124) now StaticGray Grayscale, StaticColor, PseudoColor, 

U.S. Pat No. 5,640,540, aU filed of even date herewith by DirectColor and TrueColor. The precise details of these 

the inventors hereof and assigned to the assignee herein, and cksses do nQl ^ tQ ^ defined here. At a minimum 

incorporated by reference herein. though, three of these visual classes enable an appU- 

n Ai-wrROiTTvjn of THE INVENTION cation to change the colors available to it, and three of 

BACKGROUND OF THE INVENTION ^ ^ appUcation to use the colors that the X 

1. Technical Field 35 server has predefined. That is, StaticGray, StaticColor 
The present invention relates generally to video display and TrueColor create colormaps that are **read only", 

management over a networking system and more wn ile the other visual types create colormaps that are 

specifically, to a networking system having conferencing **read/write." 

capabilities to allow conferenced appUcations to compensate 3. Number of available entries 

for differences in visual types between conference servers. ^ This indicates the number of independent colors that the 

Additionally, the present invention relates specifically to a server can make available to an appUcation at one time, 

method for classifying pairs of visual types as compatible Every X server defines to each appUcation the precise visual 

and incompatible in a networking system using heterog- types mat lt SU pports. Each visual type definition includes a 

enous hardware. value for the depth, visual class and number of available 

2. Description of the Related Art 45 entries for that type. 

X Windows provides distributed client/server support for A problem arises when the X Windows conferencing 

two dimensional graphics support The X server manages enabler connects to X servers that differ in their available 

the display of two dimensional graphics within windows on visual types. When the appUcation connects to the confer- 

behalf of the appUcation. The X Window conferencing encing enabler, the enabler must inform that appUcaUon 

enabler appears to the appUcation to be an X server, while 50 which visual types are available. From that point forward, 

at the same time appearing to the X server as an appUcation. the appUcation must be able to use any or all of those visual 

The X Windows conferencing enabler then connects to types. This must be true, even if another X server with 

multiple X servers on behalf of the appUcation, displaying significantly different visual types joins a conference after 

the appUcation *s windows on each display. The appUcation the appUcation has been made aware of its available visual 

is not aware mat it is bemg displayed on miU^ 55 types. If , in the course of execution an appUcation in a 

Such a networking system is fully described in commonly conference attempts to use a visual type or a characteristic 

assigned patent appUcation A Method And System For of a visual type that is not available on an X server in that 

Switching Between Users In A Conference Enabled conference, that X server will not execute the requested 

Application, Ser. No. 08/387,500, now U.S. Pat No. 5,537, action. If the X conferencing enabler does not compensate 

725 incorporated herein by reference for aU purposes. 60 for the differences in visual types in a conference, applica- 

In the absence of a conferencing enabler, the appUcation tions would not be able to run within a conference in which 

connects to an X server and communicates with it using X the X servers were not identical in their support of visual 

protocol, and asks the X server to create resources such as types. 

X windows on the server. In addition, the X server has Accordingly, what is needed is a method for enabling an 

resources that it has defined that may be used by any 65 X Windows conferencing enabler to compensate for difler- 

applicauon that is connected to that server. In general, ences in visual types between X servers. Specifically, the X 

resources that are created by the server are those that conferencing enabler may determine the best mapping avail- 
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able between visual types such that X windows applications BRIEF DESCRIPTION OF THE DRAWINGS 

run in conferences in which the : Xservers in that conference ^ ^ ^^^^^^^ 

date m tl^ support of «sual types. are set forth in the appended claims. The invention itself 

What U also needed is a method for das^mg pairs of however, as well as a preferred mode of use. further objects 

visual types as cornpaUWeand incompatible to allow the 5 ^ stages thereof, will best be understood by reference 

conference enabler to support X windows applications in . ^ n ^V M . ^ A ^~;~+:~~ , an j lliit .. t . ro 

c tL 4 . , v ^ * j -ir * *u • „ ~+ to the following detailed description of an illustrative 

conferences that uivolye X servers that differ in then- support embodiment wh ^ read m conjun ^ on with me accorapa . 

of vjsual types and to detect when an X server in the g j,,™, wherei n : 

conference has encountered a sever error as a result or me ' ° * 

differences in visual types. 10 FIG. 1 depicts in accordance with a preferred embodiment 

of the present invention a flowchart depicting the method to 

SUMMARY OF THE INVENTION determine the best match that is available for the conference 

owner's visual type; 

It is therefore one object of the present invention to _ * . . . „ t .„ t 

provide video display management over a networking sys- . ™- 2 1S a flowchart UlustraUng the alternative 

^ 15 implementation in accordance with a preferred embodiment 

It is another object of the present invention to provide a of the present invention, , ... 

networking system having conferencing capabilities to FIG. 3 depicts a block diagram of a flowchart detailing the 

allow conferenced applications to compensate for differ- F^cess to create lists of available compatible and incom- 

ences in visual types between conference servers. ^ P atible visual t > f P cs - 

It is yet another object of the present invention to provide DETAILED DESCRIPTION OF THE 
a method for classifying pairs of visual types as compatible PREFERRED EMBODIMENT 
and incompatible in a networking system using heterog- 
enous hardware. A representative conference enabled network system is 

The foregoing objects are achieved as is now described. „ described in commonly assigned U.S. patent application Ser. 

According to the present invention, a conference enabled X No. 08/387.502, entitled Method For Managing Top-Uvel 

windows networking system using a method for determining Windows Within A Conferencing Network System, incorpo- 

the best match available for a conference owner's visual rated herein by reference for all purposes. When an appli- 

type is disclosed. In the system, the enabler determines if the cation connects to the X Windows conferencing enabler, the 

visual type detected in the X protocol stream is the confer- 30 enabler then attempts to connect to each X server in the 

ence owner* s default visual type, in which case it is matched conference on behalf of that application. If the connection is 

to the participant's default visual type. If thai is not the case, successful, each X server sends a reply to the enabler mat 

die system determines if a visual type is available on the deludes a list of all of the visual types supported on that X 

participant which is compatible to that being referred to in server. The conferencing enabler then stores the lists of 

the X protocol. If so, the system determines which of the 35 available visual types for each X server in the conference 

compatible visual types is the best match to mat being used and returns the reply to the application that contains the hst 

by toe appUcation, If there is an exact match of compatible that was received from the conference owner. At this point 

visual type, the system matches the participant's visual type the application believes that it has all of the visual types of 

to that of the conference owner. If there are no compatible the conference owner available to it 

matches, the system will determine if an incompatible match ^ When the conferencing enabler detects an X protocol 

exists between the participant's available incompatible (step 106) that contains a reference to a visual type (step 

visual types and the visual type being used in the X protocol 108), the X conferencing enabler must select a visual type on 

If there are no incompatible visual types available, the each X server that best matches the requested visual type, 

system signals an error condition and takes the appropriate The X conferencing enabler compares the list of available 

action. When a match is made between a participant's visual 45 visual types for each X server in the conference with that of 

type and that of the conference owner, the matched visual the conference owner and executes the following method 

types are removed from the lists of available visual types. depicted in the flowchart of FIG. 1 to determine the best 

The list of visual types is created when die X server match that is available for the conference owner's visual 

responds to a connection request from the X server confer- type. 

encing enabler. To determine the default/compatible/ 50 In step 110, the enabler determines if the visual type to be 

incompatible state of visual types available on a partici- matched is the conference owner's default visual type, and 

pant's X server, the system compares the characteristics of if so, in step 112, then it should be matched to the default 

the conference owner's visual type being used to those of visual type of the conference participant's X server, 

each of the participant's visual types. Tbe visual types are Otherwise, in step 114, if there is an available visual type on 

compatible if the conference owner's visual type has a 55 the conference participant's X server that is compatible to 

greater number of independent entries and the participant's the conference owner's visual type, in step 116, the best 

visual type is read only. In addition the visual types are compatible visual type should be used (step 124 or 126). If 

compatible if the conference owner's visual type-has the not, in step 118, if there is an available incompatible visual 

same number or fewer independent entries than that of the type on the conference participant's X server, in step 120, 

participant and the conference owner's type is read/write. 50 the best incompatible visual type on the participant's X 

Finally, they are compatible if the conference owner's visual server should be matched to the conference owner's visual 

type has fewer independent entries than that of the type. Once a match is made (steps 112, 129, 126), the system 

participant, and both the conference owner's visual type and removes the matched visual types from the list of available 

that of the participant are read only. visual types in step 128 before returning to step 106. 

The above as well as additional objects, features, and 65 If , in step 118. it is determined that there are no incom- 

advantages of the present invention will become apparent in patible visual types available (and therefore no available 

the following detailed written description. visual types at all), then the application cannot be run with 
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this X server in the conference. The conferencing enable* 
then, in step 122, determines what the appropriate action is 
in this error condition. It may be that this participant's X 
server will no longer be permitted to interact with the 
application. 

Another way of looking at the implementation of FIG. 1 
is to place all of the available visual types on the conference 
participant's X server are placed into one of three categories: 

1. default visual 

2. compatible visual types 

3. incompatible visual types 

These categories are examined in the order stated here. If a 
category is found that is non-empty, the visual type within 
that category that best matches the conference owner's 
visual type is used. Once an available visual type is matched 
with one on the master's X server, it is removed from the list 
of available visual types. FIG. 2 depicts a flowchart illus- 
trating the alternative implementation. 

If. in step 218, the default visual category is not empty and 
the application, in step 220. is attempting to use the confer- 
ence owner's default visual type, then, in step 222. the match 
is made between the default visual types. 

If, in steps 224 or 230, one of the other categories is 
determined to be appropriate and there is more man one 
possible visual type within that category, then the method 
proceeds to steps 226 or 232 to determine the best visual 
type within that category. Otherwise, in step 238, there is an 
error condition. 

In step 226, the system determines if there is an exact 
match between the conference owner's visual type and the 
participant's visual type, then match these two visual types 
(step 228). If not, in step 232, the system determines if the 
conference owner' s visual type is read only, and if so. in step 
234. the system selects the closest visual type (as defined 
below) that is also read only (step 236). If this is not 
possible, then, in step 240, the system selects the closest 
visual type (as defined below) that is read/write. Once a 
match is made, it is removed from the list in step 242. 



X server in the conference. This is important because of the 
structure of the X protocol. That is, the default visual type 
is provided to the application so that the application may 
entirely avoid taking advantage of the special characteristics 
5 of the visual types. It allows the application not to specify 
the details of color handling in several of the X protocol. If 
an application chooses to use the default visual type, this 
indicates that it will not be providing some information to 
the X server, but rather that it allows the X server to use its 
10 default values. Since this information is dispersed through- 
out the X protocol, it greatly simplifies the X conferencing 
enabler to assume that toe default visual types are always 
matched to each other. 
Another consideration is that toe visual types are matched 
15 on a per-appli cation basis. That is, toe best match of visual 
types is determined when it is first referred to by toe 
application, rather than determining the best match of visual 
types when the connections to toe X servers are initially 
established. This allows the conferencing enabler to provide 
20 the best possible match for each application in the 
conference, thus providing a higher probability that each 
application will be able to execute cleanly in the conference. 

Once it is determined that either the compatible visual 
type category or the incompatible visual type category has 
25 more than one potential match, it is significant that within 
that category, the visual type that is chosen has the same 
read/write characteristics as the visual type that is being 
matched. This is important because once an application has 
selected a visual type — be It a read only visual type or a 
30 read/write visual type — subsequent protocol used by the 
application assumes that capability of the visual type. It is 
difficult although not impossible, to compensate for this 
type of difference in visual types. Therefore, it is desirable 
for the X conferencing enabler to avoid this difficulty. 
35 Once that visual type matching is defined by the confer- 
encing enabler and toe application is able to use the visual 
type of its choice, it is possible that errors may occur on any 
or all of the X servers in the conference as a result of the 
application using the characteristics of that visual type. 



For the purposes of this embodiment in FIG. 2. the ^ ^ Jaise either because the application itself 



"closest" is determined by toe values assigned by the X 
protocol for each of the visual types. That is, toe X protocol 
defines each of the visual types a numerical value as follows: 





numerical 
value 


read only? 


StaticGray 


0 


y 


Grayscale 


1 


□ 


StaticCotor 


2 


y 


Pseudocolor 


3 


D 


TrueColcr 


4 


y 


DirectCok* 


5 


a 



is in error or because one or more of the X servers are in a 
state such that the request may not be granted. Depending 
upon toe visual type matching performed by the conferenc- 
ing enabler, these errors may or may not be reasonably 
45 expected by the application. That is, based on toe visual type 
used by an application, that application should reasonably be 
able to deal with certain errors from the X server. Other 
errors that may be generated by an X server that does not 
have a visual type identical to that which the application 
50 believes it is using, may not be expected by the application. 
Sending these errors to the application could cause it to 
behave in an unpredictable manner. 
As an application in a conference uses visual types, toe 
When more than one visual type is determined to be the conferencing enabler is able to determine which of the visual 
"closest" to toe visual type to match, the visual type that has 55 types available on each of the X servers in the conference is 
toe higher numerical value is considered to be the best the best match to the one requested by toe application. As 
match, part of the process of determining which visual type is the 

Since visual types are contained in both requests from toe best match, each visual available is classified as either 
application and replies sent from toe X server, a visual type compatible or incompatible with toe visual type requested 
is considered to be "used" by the application if it is referred 60 by the application. 

to in either a request or reply. For this reason, it is important Compatible and incompatible visual types are differenU- 
that each visual type used by an application be mapped to ated by the potential differences in their response to client 
one and only one visual type on each X server's visual type requests to use colors. The conference enabler defines an 
and the visual type referred to by the application, those incompatible visual type as one that might generate an error 
visual types may not be matched to any other visual type. 65 that the application does not expect Conversely, a compat- 
As stated above, the default visual type of toe conference ible visual type is one that does not generate an error that the 
owner is always matched to the default visual type of each application cannot reasonably expect Note that toe differ- 
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encc is not the visual types* ability to return an error in 
response to an application request. Indeed, an error may be 
an appropriate response to an invalid request or may be an 
appropriate and expected response from an X server that is 
not able to execute the application's request The difference 
between compatibility and incompatibility lies in whether or 
not the application could reasonably be expected to handle 
the error that the X server may return. 

If an error is received from an X server with an incom- 
patible visual type* the conferencing enabler must detect this 
condition and take appropriate action; however, the error 
should not be sent on to the application. 

There are two characteristics of visual types that deter- 
mine whether or not two visual types are compatible. These 
are the number of entries in a colormap of (he visual type and 
whether or not the entries in the colormap are modifiable by 
the application. 

In order to understand why the ability to modify the 
colormap of the visual type is a characteristic determining 
compatibility, the system must first examine the behavior of 
the X server when a modifiable visual type is being used. As 
stated earlier, there are six visual classes supported by X 
windows. Of these six classes, three of them allow an 
application to change the entries in the associated colormap 
(that is. they allow entries in the colormap to be allocated as 
read/write or read only) and three of them do not These 
classes are separated as follows: 



readonly read/write 

StatieGray Grayscale 

StaticColor PseudoColor 

TrueColor DirectCotor 



Through the X protocol an application has an option of 
allocating an entry in the colormap as either read only or 
read/write. The behavior of the X server in response to a 
request to allocate an entry differs based on the visual type 
which is being used. The conditions are summarized in the 
following table: 

TABLE 1 



Summary of visual type responses to an application request to 
allocate an entry in its colormap. 

server response to server response to 

read only read/write 
allocation attempt allocation attempt 



READ ONLY Closest available pixel Always an error, 

visual types allocated. Never an error 

READ/WRITE Exact pixel allocated or Exact pixel allocated 

visual types error if colormap is full or error if colormap is full. 



The underlying principle of compatibility of visual types 
is that two visual types are compatible while involved in a 
conference if and only if they do not generate errors which 
the application cannot reasonably expect to encounter. For 
instance* an application that believes it is using a read/only 
visual type (e.g.. StaticColor) and issues a request to allocate 
a read/only entry in the colormap cannot reasonably expect 
to get an error stating that the colormap is fulL Therefore, 
read/write visual types on an X server are incompatible with 
read/only colormaps of the application. 

This compatibility principle leads to the following matrix 
in Table 2, displaying the compatibility of visual types that 
are used by the application and each X server in a confer- 
ence. Note that since the issue of relative number of inde- 
pendent entries in a colormap will be dealt with in the 
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following section, this matrix applies only to the situation 
when the X server's visual type has an equal or greater 
number of entries than that expected by the application. 
Those positions marked with an 44 X* t indicate pairs of 
5 compatible visual types. All other pairs are incompatible. 

TABLE 2 



Visual types mat are compatible when the application's visual type 
has the tame number or fewer number of independent entries as 



that of the X server. 





X SERVER 


Static 


Gray 


Static 


Pseudo 


True 


Direct 




VISUAL TYPE: 


Gray 


Scale 


Color 


Color 


Color 


Color 




APPLICATION 


X 




X 




X 




15 


VISUAL TYPE: 
















Static Gray 
















Gray Scale 


X 


X 


X 


X 


X 


X 




Static Color 


X 




X 




X 






Pseudo Color 


X 


X 


X 


X 


X 


X 




True Color 


X 




X 




X 




20 


Direct Color 


X 


X 


X 


X 


X 


X 



The number of entries in a colormap of a visual type is the 
second indicator of compatibility of two visual types, con- 
sider the case of an application mat creates its own colormap 

25 of visual type. A. When the application creates this 
colormap, it is aware of the fact that visual type A allows a 
certain number of entries. For example, assume that visual 
type A is a read/write visual type, which allows 4096 
independent entries in its colormap. At this point, if the 

30 application should so choose, it should be able to allocate 
4096 independent entries in mis colormap that it created. 
Now. suppose the conferencing enabler had determined that 
the best match for visual type A available on a certain X 
server was visual type B, which is a read/write colormap 

35 with only 256 independent entries. When the application 
attempted to allocate more man 256 entries in its colormap, 
the second X server would generate an error. This would be 
an error that could not reasonably be expected by the 
application and therefore indicates that these two visual 

40 types are incompatible. 

Note that, as previously described, a read only visual type 
never returns an error because it could not allocate an entry 
in its colormap. Therefore, the number of independent 
entries in a visual type will only impact the compatibility of 

43 visual types that are modifiable. 

Table 3 below shows a matrix that defines the compat- 
ibility of visual types when the application assumes that it 
has a greater number of independent entries in its colormap 
than the X server actually has available. 

50 Those positions marked with an "XT' indicate pairs of 
compatible visual types. 

TABLE 3 

55 Visual types that are compatible when the application's visual type 
has a greater numhrr P f irK V»p»nA»nt entries than that of the X server. 

X SERVER Stalk Gray Static Pseudo True Direct 

VISUAL TYPE: Gray Scale Color Color Color Color 



„ APPLICATION XX X 
W VISUAL TYPE: 
Stalk Gray 

Grayscale XX X 

StaticColor XX X 

PseudoColor XX X 

TrueColor XX X 

65 Direct Color X X 
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In algorithmic form. Tables 2 and 3 can be used to create 
lists of compatible and incompatible visual types. 

FIG. 3 depicts a block diagram of a flowchart detailing the 
process to create lists of available compatible and incom- 
patible visual types. Id step 310. the system determines if 5 
there are any or more X server visual types to compare. If 
so, in step 312, the system then determines whether the 
application visual number of entries is less than or equal to 
the X server visual number of entries, and if so, then 
proceeds to step 316. Otherwise, the system proceeds to step 10 
314 where the system determines whether the X server 
visual is a read or write function, and if so, proceeds to step 
320, otherwise, it proceeds to step 322. 

In step 316, the system determines whether the applica- 
tion visual type is a read only operation. If the application 15 
visual type is a read only, the system proceeds to step 318, 
where it determines if the X server visual type is a read/write 
type. If the application visual type is neither a read nor a 
read/write type, then the system proceeds to step 320. where 
the system determines if the X server visual type is com- 20 
patible with the application visual type. If the application 
visual type is a read only and a read/write type, then the 
system, in step 322, determines that the X server visual is 
incompatible with the application visual type and then 
returns to step 310 to continue processing for additional X 25 
server visual types to be compared. 

While the invention has been particularly shown and 
described with reference to a preferred embodiment, it will 
be understood by those skilled in the art that various changes 
in form and detail may be made therein without departing 30 
from the spirit and scope of the invention. 
We claim: 

1. In a conference enabled windows network system, a 
method for determining the best match available for a 
conference owner's visual type for each server connected to 35 
said windows network system, comprising the steps of: 

determining if a default visual type for said server is 
available to match said conference owner's default 
visual type; 

deterniining if a participant has an available visual type 
compatible with said conference owner's visual type; 
and 

matching said visual type of said participant to a visual 
type most compatible to said owner's visual type. 45 

2. The method according to claim 1 further comprising the 
step of: 

removing a matched visual type from a list of available 
visual types. 

3. The method according to claim 1 wherein said step of 50 
matching to the closest compatible visual type available 
further comprises the steps of: 



detennining if there is an exact match of visual types; and 
upon determining there is an exact match visual type, 
matching said exact match to the owner's visual type. 

4. The method according to claim 1 further comprising the 
step of: 

upon determining said visual type is incompatible with 
said owner's visual type, matching to a closest incom- 
patible visual type available. 

5. The invention according to claim 1 further comprising 
the step of providing an error condition in the event that 
either a compatible or incompatibie visual type is not 
available. 

6. In a conference enabled windows network system 
having a plurality of X servers, one of said X servers 
receiving an application on said network system, a method 
of generating a list of available compatible visual types 
comprising the steps of: 

detennining if said application's visual type has the same 
number or fewer number of independent entries as that 
of said X server, 

if so, determining if an available visual type for a par- 
ticular X server is read only or if the application's 
visual type is read/write; and 

if not, deteriruning if an available visual type for a 
particular X server is read only. 

7. The method according to claim 6 further comprising the 
step of: 

detennining the particular X server's visual type based on 
its coinpatibility with (he application's visual type. 

8. In a conference enabled windows network system 
having a plurality of X servers, one of said X servers 
receiving an application on said network system* a method 
of generating a list of available incompatible visual types 
comprising the steps of: 

determining if said application's visual type has the same 

number or fewer number of independent entries as that 

of the X server; 
if so. detennining if the application's visual type is read 

only and if a particular X server's visual type is 

read/write; and 
if not, determining if the particular X server's visual type 

is read/write. 

9. The method according to claim 8 further comprising the 
step of: 

determining the particular X server's visual type based on 
its compatibility with the application's visual type. 
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